A Machine to Machine (abbreviated as M2M) communication network is composed of various M2M nodes and a bearer network. The M2M nodes communicate with each other through the bearer network, and one M2M node can include but not limited to: an application entity or a common service entity. The application entity is a logic unit which practically executes the M2M application, and the common service entity is a logic unit which performs management and service on the application.
In the M2M system architecture, the application node is an endmost execution node, for example, an intelligent electric meter, a temperature measurement and control sensor, a fire alarm, an intelligent home appliances, etc. While an intermediate node is a middleware which connects the endmost execution node to a network side server, for example, a gateway; the base node is a network side server, herein, the application entity registered on the base node is usually a management software or management platform of the M2M service provider.
FIG. 1 is a schematic diagram of an M2M system architecture based on the existing technology. As shown in FIG. 1, the communication between the M2M applications in general is achieved through the interaction between the Common Service Entities (abbreviated as CSE). While the premise of the communication is that the M2M application first needs to register in the local CSE (for example, the application entity on the application node in FIG. 1 needs to register to the CSE on the intermediate node, then the CSE on the intermediate node is a local CSE of the application entity on the application node), and then the interaction between the M2M applications is achieved through the communication between the local CSEs.
The application node is a physical entity, and the application entity (abbreviated as AE) is a logical unit, which is a logical unit that really executes the application on the application node, that is, the physical entity. The AE can create resources on the local CSE as per requirement, and each resource has a corresponding attribute to identify the characteristics of the resource.
However, in the existing technology, when a resource is created, its attribute is also created synchronically. If it is required to add a new attribute, or delete an existing attribute, then the resource must be first deleted, and then a resource is re-created, and the new attribute is created synchronically when creating the resource, and the attribute which is required to be deleted will be ignored and will not be created again when creating the resource. The reason for using the above operating procedures is that: the existing creation operation can only support the operation on the resource, while not support the operation on the attribute, which leads to that any operation of adding and/or deleting attributes must be completed by re-creating the resource.
It can be seen that the existing technology is short of a technical solution for executing any operation on the attribute without re-creating the resource.